ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group93c.txt/000021_icon-group-sender _Wed Jul 21 06:12:42 1993.msg

Internet Message Format | 1994-02-02 | 3KB

Received: by cheltenham.cs.arizona.edu; Wed, 21 Jul 1993 08:43:02 MST
Message-Id: <[e-mail]>
From: [e-mail] (Steve Wampler)
Date: Wed, 21 Jul 1993 06:12:42 MST
In-Reply-To: [e-mail]'s mail message of Jul 20,  9:35pm.
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
To: [e-mail]
Subject: Re: Mysteries of "every"
Status: R
Errors-To: [e-mail]

On Jul 20 at  9:35pm, [e-mail] writes:
}
} Cary Coutant wrote the following in response to my query:
} -----------------------------
}  >    every retval :=  8 * retval + ord(!s) - ord("0")
}  >
}  > Now the output of the program is 3 (the last digit), not 83.
}  >
}  > Can anyone explain to me what's going on?
}
}  Try reversing the operands of the "+" operation:
}
}      every retval := ord(!s) - ord("0") + 8 * retval
}
}  Your problem was that the every was resuming the expression
}  from the last suspended generator, so "8 * retval" was never
}  being reevaluated.
}
}  In situations like this, it's sometimes useful to replace a
}  built-in operator with your own procedure, so you can see
}  what's going on by setting TRACE.  For example:
}
}      every retval :=  add(8 * retval, ord(!s) - ord("0"))
} -----------------------------------
}
} This explanation satisfies the ultimate test: Cary's version works.
}
} Yet I've looked again at pages 15-16 of the Icon book and I still don't
} get it.  The explanation of resumption on p. 15 is in terms of failure,
} and there's no failure in the expression of my example.  The description
} of "every" on p. 16 says that "expr1 is first evaluated and then
} repeatedly resumed to produce all its values."  I would have thought that
} resuming an expression that doesn't fail would cause it to be
} =completely= reevaluated.
}
} Clearly the assignment, which is the outermost level of the expression,
} is evaluated on each iteration.  In fact, I verified (by attaching a
} "do") that with s="123", retval takes on successive values of 1,2,3.  Yet
} the second retval is not being reevaluated.  So which parts of an
} expression are reevaluated and which ones aren't?  Is there any way to
} deduce what happens from the explanation in the Icon book?
}
} I'd appreciate any help I can get on this.  I'd also suggest that you
} post your comments to icon-group rather than sending them to me
} personally.
}

Well, actually, there *is* a failure.  It's inherent in the semantics
of every.  For all practical purposes,

    every expr

is equivalent to:

    (expr) & &fail

(It gets a little trickier to describe the behavior when a 'do clause'
is present, of if there is a 'break' or 'next' in the expr....).

'Resumption' is also always a LIFO operation on generators, whether you
care to think of every as above or as a separately semantic concept.
It is fundamentally different than 'reevaluation'.  If you were to
try and develop a non-LIFO model for resumption, it gets *very* tricky
to still guarantee the combinatorial effects of multiple generators.
In particular, you cannot use a stack based evaluation model.

Note that you can experiment with other models for resumption with
Co-expressions, if you want to see what problems arise!
~t

--
Steve Wampler
[e-mail]
Gemini Project (under AURA)